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Abstract 
This document provides procedures for registering extensible elements 
of the Lightweight Directory Access Protocol (LDAP). This document 
also provides guidelines to the Internet Assigned Numbers Authority 
(IANA) describing conditions under which new values can be assigned. 


1. Introduction 


The Lightweight Directory Access Protocol (LDAP) [RFC3377] is an 
extensible protocol. LDAP supports: 


— addition of new operations, 
- extension of existing operations, and 
- extensible schema. 


This document details procedures for registering values of used to 
unambiguously identify extensible elements of the protocol including: 


- LDAP message types; 

- LDAP extended operations and controls; 
- LDAP result codes; 

- LDAP authentication methods; 

- LDAP attribute description options; and 
- Object Identifier descriptors. 


These registries are maintained by the Internet Assigned Numbers 
Authority (IANA). 
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In addition, this document provides guidelines to IANA describing the 
conditions under which new values can be assigned. 

2. Terminology and Conventions 
This section details terms and conventions used in this document. 

2.1. Policy Terminology 
The terms "IESG Approval", "Standards Action", "IETF Consensus", 


"Specification Required", "First Come First Served", "Expert Review", 
and "Private Use" are used as defined in BCP 26 [RFC2434]. 


2.2. Requirement Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOI", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in BCP 14 [RFC2119]. In 
this case, "the specification" as used by BCP 14 refers to the 
processing of protocols being submitted to the IETF standards 
process. 


2.3. Common ABNF Productions 


A number of syntaxes in this document are described using ABNF 


[RFC2234]. These syntaxes rely on the following common productions: 
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 
LDIGIT = %x31-39 $29 
DIGIT = $x30 / LDIGIT ; 0-9 


HYPHEN = $x2D PAES 
DOT = $x2E LU 
number = DIGIT / ( LDIGIT 1*DIGIT ) 
keychar = ALPHA / DIGIT / HYPHEN 
leadkeychar = ALPHA 
keystring = leadkeychar *keychar 
A keyword is a case-insensitive string of UTF-8 [RFC2279] encoded 


characters from the Universal Character Set (UCS) [ISO10646] 
restricted to the «keystring» production. 
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3. IANA Considerations for LDAP 


This section details each kind of protocol value which can be 
registered and provides IANA guidelines on how to assign new values. 


IANA may reject obviously bogus registration requests. 
3.1. Object Identifiers 


Numerous LDAP schema and protocol elements are identified by Object 
Identifiers. Specifications which assign OIDs to elements SHOULD 
state who delegated the OIDs for its use. 


For IETF developed elements, specifications SHOULD use OIDs under 
"Internet Directory Numbers" (1.3.6.1.1.x). Numbers under this OID 
arc will be assigned upon Expert Review with Specification Required. 
Only one OID per specification will be assigned. The specification 
MAY then assign any number of OIDs within this arc without further 
coordination with IANA. 


For elements developed by others, any properly delegated OID can 
be used, including those under "Internet Private Enterprise 
Numbers" (1.3.6.1.4.1.x) assigned by IANA 
<http://ww.iana.org/cgi-bin/enterprise.pl>. 


To avoid interoperability problems between early implementations of 
"works in progress" and implementations of the published 
Specification (e.g., the RFC), experimental OIDs SHOULD be used in 


"works in progress" and early implementations.  OIDs under the 
Internet Experimental OID arc (1.3.6.1.3.x) may be used for this 
purpose. 


Experimental OIDs are not to used in published specifications (e.g., 
RFCs). 


Practices for IANA assignment of Internet Enterprise and Experimental 
OIDs are detailed in STD 16 [RFC1155]. 


3.2 Protocol Mechanisms 


LDAP provides a number of Root DSE attributes for discovery of 
protocol mechanisms identified by OIDs, including: 


- supportedControl [RFC2252] and 
- supportedExtension [RFC2252]. 
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A registry of OIDs used for discover of protocol mechanisms is 
provided to allow implementors and others to locate the technical 
specification for these protocol mechanisms. Future specifications 
of additional Root DSE attributes holding values identifying protocol 
mechanisms MAY extend this registry for their values. 


OIDs associated with discoverable protocol mechanisms SHOULD be 
registered. These are be considered on a First Come First Served 


with Specification Required basis. 


OIDs associated with Standard Track mechanisms MUST be registered and 
require Standards Action. 


3.3. Object Identifier Descriptors 


LDAP allows short descriptive names (or descriptors) to be used 
instead of a numeric Object Identifier to identify protocol 
extensions [RFC2251], schema elements [RFC2252], LDAP URL [RFC2255] 
extensions, and other objects. Descriptors are restricted to strings 
of UTF-8 encoded UCS characters restricted by the following ABNF: 


name = keystring 
Descriptors are case-insensitive. 
Multiple names may be assigned to a given OID. For purposes of 
registration, an OID is to be represented in numeric OID form 
conforming to the ABNF: 

numericoid = number *( DOT number ) ; e.g., 1.1.0.23.40 
While the protocol places no maximum length restriction upon 
descriptors, they should be short. Descriptors longer than 48 
characters may be viewed as too long to register. 
A values ending with a hyphen ("-") reserve all descriptors which 
start with the value. For example, the registration of the option 
"descrFamily-" reserves all options which start with "descrFamily-" 


for some related purpose. 


Descriptors beginning with "x-" are for Private Use and cannot be 
registered. 


Descriptors beginning with "e-" are reserved for experiments and will 
be registered on a First Come First Served basis. 


All other descriptors require Expert Review to be registered. 
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The registrant need not "own" the OID being named. 


The OID namespace is managed by The ISO/IEC Joint Technical Committee 
1 - Subcommittee 6. 


3.4. AttributeDescription Options 


An AttributeDescription [RFC2251, Section 4.1.5] can contain zero or 
more options specifying additional semantics. An option SHALL be 
restricted to a string UTF-8 encoded UCS characters limited by the 
following ABNF: 


option = keystring 
Options are Case-insensitive. 


While the protocol places no maximum length restriction upon option 
strings, they should be short. Options longer than 24 characters may 
be viewed as too long to register. 


Values ending with a hyphen ("-") reserve all option names which 
start with the name. For example, the registration of the option 
"optionFamily-" reserves all options which start with "optionFamily-" 
for some related purpose. 


Options beginning with "x-" are for Private Use and cannot be 
registered. 


Options beginning with "e-" are reserved for experiments and will be 
registered on a First Come First Served basis. 


All other options require Standards Action or Expert Review with 
Specification Required to be registered. 


3.5. LDAP Message Types 


Each protocol message is encapsulated in an LDAPMessage envelope 
[RFC2251, Section 4.1.1]. The protocolOp CHOICE indicates the type 
of message encapsulated. Each message type consists of a keyword and 
a non-negative choice number is combined with the class (APPLICATION) 
and data type (CONSTRUCTED or PRIMITIVE) to construct the BER tag in 
the message's encoding. The choice numbers for existing protocol 
messages are implicit in the protocol's ASN.1 defined in [RFC2251]. 


New values will be registered upon Standards Action. 


Note: LDAP provides extensible messages which reduces, but does not 
eliminate, the need to add new message types. 
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3.6. LDAP Result Codes 


LDAP result messages carry an resultCode enumerated value to indicate 
the outcome of the operation [RFC2251, Section 4.1.10]. Each result 
code consists of a keyword and a non-negative integer. 


New resultCodes integers in the range 0-1023 require Standards Action 
to be registered. New resultCode integers in the range 1024-4095 
require Expert Review with Specification Required. New resultCode 
integers in the range 4096-16383 will be registered on a First Come 
First Served basis. Keywords associated with integers in the range 
0-4095 SHALL NOT start with "e-" or "x-". Keywords associated with 
integers in the range 4096-16383 SHALL start with "e-". Values 
greater than or equal to 16384 and keywords starting with "x-" are 
for Private Use and cannot be registered. 


3.7. LDAP Authentication Method 
The LDAP Bind operation supports multiple authentication methods 
[RFC2251, Section 4.2]. Each authentication choice consists of a 


keyword and a non-negative integer. 


The registrant SHALL classify the authentication method usage using 
one of the following terms: 


COMMON - method is appropriate for common use on the 
Internet, 

LIMITED USE - method is appropriate for limited use, 

OBSOLETE - method has been deprecated or otherwise found to be 


inappropriate for any use. 


Methods without publicly available specifications SHALL NOT be 
classified as COMMON. New registrations of class OBSOLETE cannot be 
registered. 


New authentication method integers in the range 0-1023 require 
Standards Action to be registered. New authentication method 
integers in the range 1024-4095 require Expert Review with 
Specification Required. New authentication method integers in the 
range 4096-16383 will be registered on a First Come First Served 
basis. Keywords associated with integers in the range 0-4095 SHALL 
NOT start with "e-" or "x-". Keywords associated with integers in 
the range 4096-16383 SHALL start with "e-". Values greater than or 
equal to 16384 and keywords starting with "x-" are for Private Use 
and cannot be registered. 


Note: LDAP supports SASL [RFC2222] as an Authentication CHOICE. 
SASL is an extensible LDAP authentication method. 
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3.8. Directory Systems Names 


The IANA-maintained "Directory Systems Names" registry [IANADSN] of 
valid keywords for well known attributes used in the LDAPv2 string 
representation of a distinguished name [RFC1779]. RFC 1779 was 
obsoleted by RFC 2253. 


Directory systems names are not known to be used in any other 
context.  LDAPv3 uses Object Identifier Descriptors [Section 3.2] 
(which have a different syntax than directory system names). 


New Directory System Names will no longer be accepted. For 
historical purposes, the current list of registered names should 
remain publicly available. 


4. Registration Procedure 


The procedure given here MUST be used by anyone who wishes to use a 
new value of a type described in Section 3 of this document. 


The first step is for the requester to fill out the appropriate form. 
Templates are provided in Appendix A. 


If the policy is Standards Action, the completed form SHOULD be 
provided to the IESG with the request for Standards Action. Upon 
approval of the Standards Action, the IESG SHALL forward the request 
(possibly revised) to IANA. The IESG SHALL be viewed as the owner of 
all values requiring Standards Action. 


If the policy is Expert Review, the requester SHALL post the 
completed form to the <directory@apps.ietf.org> mailing list for 
public review. The review period is two (2) weeks. If a revised 
form is later submitted, the review period is restarted. Anyone 
may subscribe to this list by sending a request to 
<directory-request@apps.ietf.org>. During the review, objections 
may be raised by anyone (including the Expert) on the list. After 
completion of the review, the Expert, based upon public comments, 
SHALL either approve the request and forward it to the IESG OR deny 
the request. In either case, the Expert SHALL promptly notify the 
requester of the action. Actions of the Expert may be appealed 
[RFC2026]. The Expert is appointed by Applications Area Director(s). 
The requester is viewed as the owner of values registered under 
Expert Review. 


If the policy is First Come First Served, the requester SHALL submit 
the completed form directly to the IANA: <iana@iana.org>. The 
requester is viewed as the owner of values registered under First 
Come First Served. 
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Neither the Expert nor IANA will take position on the claims of 
copyright or trademarks issues regarding completed forms. 


Prior to submission of the Internet Draft (I-D) to the RFC Editor but 
after IESG review and tentative approval, the document editor SHOULD 
revise the I-D to use registered values. 


5. Registration Maintenance 
This section discusses maintenance of registrations. 
5.1. Lists of Registered Values 


IANA makes lists of registered values readily available to the 
Internet community on their web site: <http://www.iana.org/>. 


5.2. Change Control 


The registration owner MAY update the registration subject to the 
same constraints and review as with new registrations. In cases 
where the owner is not unable or unwilling to make necessary updates, 
the IESG MAY assert ownership in order to update the registration. 


5.3. Comments 


For cases where others (anyone other than the owner) have significant 
objections to the claims in a registration and the owner does not 
agree to change the registration, comments MAY be attached to a 
registration upon Expert Review. For registrations owned by the 
IESG, the objections SHOULD be addressed by initiating a request for 
Expert Review. 


The form of these requests is ad hoc, but MUST include the specific 
objections to be reviewed and SHOULD contain (directly or by 
reference) materials supporting the objections. 


6. Security Considerations 
The security considerations detailed in [RFC2434] are generally 
applicable to this document. Additional security considerations 
Specific to each namespace are discussed in Section 3 where 


appropriate. 


Security considerations for LDAP are discussed in documents 
comprising the technical specification [RFC3377]. 
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Appendix A. Registration Templates 


This appendix provides registration templates for registering new 
LDAP values. 


A.1. LDAP Object Identifier Registration Template 

Subject: Request for LDAP OID Registration 

Person & email address to contact for further information: 

Specification: (I-D) 

Author/Change Controller: 

Comments: 

(Any comments that the requester deems relevant to the request) 
A.2. LDAP Protocol Mechanism Registration Template 

Subject: Request for LDAP Protocol Mechanism Registration 


Object Identifier: 


Description: 

Person & email address to contact for further information: 
Usage: (One of Control or Extension) 

Specification: (I-D) 

Author/Change Controller: 


Comments: 


(Any comments that the requester deems relevant to the request) 
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A.3. LDAP Descriptor Registration Template 
Subject: Request for LDAP Descriptor Registration 
Descriptor (short name): 
Object Identifier: 
Person € email address to contact for further information: 


Usage: (One of attribute type, URL extension, 
object class, or other) 


Specification: (RFC, I-D, URI) 

Author/Change Controller: 

Comments: 

(Any comments that the requester deems relevant to the request) 
A.4. LDAP Attribute Description Option Registration Template 

Subject: Request for LDAP Attribute Description Option Registration 

Option Name: 

Family of Options: (YES or NO) 

Person & email address to contact for further information: 

Specification: (RFC, I-D, URI) 

Author/Change Controller: 


Comments: 


(Any comments that the requester deems relevant to the request) 
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A.5. LDAP Message Type Registration Template 


Subject: Request for LDAP Message Type Registration 

LDAP Message Name: 

Person € email address to contact for further information: 

Specification: (Approved I-D) 

Comments: 

(Any comments that the requester deems relevant to the request) 
A.6. LDAP Result Code Registration Template 

Subject: Request for LDAP Result Code Registration 

Result Code Name: 

Person € email address to contact for further information: 

Specification: (RFC, I-D, URI) 

Author/Change Controller: 

Comments: 

(Any comments that the requester deems relevant to the request) 
A.7. LDAP Authentication Method Registration Template 

Subject: Request for LDAP Authentication Method Registration 

Authentication Method Name: 

Person € email address to contact for further information: 

Specification: (RFC, I-D, URI) 


Intended Usage: (One of COMMON, LIMITED-USE, OBSOLETE) 


Author/Change Controller: 
Comments: 


(Any comments that the requester deems relevant to the request) 
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Appendix B. Assigned Values 
The following values are currently assigned. 
B.1. Object Identifiers 


Currently registered "Internet Private Enterprise Numbers" can be 
found at <http://www.iana.org/assignments/enterprise-numbers>. 


Currently registered "Internet Directory Numbers" can be found at 
<http://www.iana.org/assignments/smi-numbers>. 


B.2. Protocol Mechanisms 


Object Identifier Type Description Reference 
1.2.840.113556.1.4.473 C Sort Request [RFC2891] 
1.2.840.113556.1.4.474 C Sort Response [RFC2891] 
1.3.,6.1.4.1.1466.101.119;1 E Dynamic Refresh  [RFC2589] 
1.3.6.1.4.1.1466.20037 E Start TLS [RFC2830] 
1:34.6.1.4.1.42038.1.11.1 E Modify Password  [RFC3062] 
2.16.840.1.113730.3.4.2 C ManageDsaIT [RFC3296] 


C => supportedControl 
E => supportedExtension 


B.3. Object Identifier Descriptors 


NAME Type OID [REF] 

account O 0.9.2342.19200300.100.4.5 [RFC1274] 
alias O 2.5.6.1 [RFC2256] 

aliasedEntryName Avge Ask. (EX. 501] 

aliasedObjectName A 2.5.4.1 [RFC2256] 

altServer A 1.3.6.1.4.1.1466.101.120.6 [RFC2252] 
applicationEntity O 2.5.6.12 [RFC2256] 
applicationProcess O 2.5.6.11 [RFC2256] 

aRecord A 0.9.2342.19200300.100.1.26 [RFC1274] 
associatedDomain A 0.9.2342.19200300.100.1.37 [RFC1274] 
associatedInternetGateway A 1.3.6.1.4.1.453.7.2.8 [RFC2164] 
associatedName A 0.9.2342.19200300.100.1.38 [RFC1274] 
associatedORAddress A 1.3.6.1.4.1.453.7.2.6 [RFC2164] 
associatedX400Gateway A 1.3.6.1.4.1.453.7.2.3 [RFC2164] 
attributeTypes A 2.5.21.5 [RFC2252] 

audio A 0.9.2342.19200300.100.1.55 [RFC1274] 
authorityRevocationList A 2.5.4.38 [RFC2256] 
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bitStringMatch .13.16 [REC2252] 

buildingName .2342.19200300.100.1.48 [RFC1274] 
businessCategory .4.15 [RFC2256] 

E .4.6 [RFC2256] 

cACertificate .4.37 [RFC2256] 

calCalAdrURI .840.113556.1.4.481 [RFC2739] 
calCalURI .840.113556.1.4.478 [RFC2739] 
calCAPURI .840.113556.1.4.480 [RFC2739] 
calEntry .840.113556.1.5.87 [RFC2739] 
calFBURL .840.113556.1.4.479 [RFC2739] 
calOtherCalAdrURIs .840.113556.1.4.485 [RFC2739] 
calOtherCalURIs .840.113556.1.4.482 [RFC2739] 
calOtherCAPURIs .840.113556.1.4.484 [RFC2739] 
calOtherFBURLs .840.113556.1.4.483 [RFC2739] 
caseExactIA5Match .6.1.4.1.1466.109.114.1 [RFC2252] 
caselgnorelA5Match .6.1.4.1.1466.109.114.2 [RFC2252] 
caselgnoreListMatch .13.11 [RFC2252] 

caselgnoreMatch .13.2 [RFC2252] 


.13.3 [RFC2252] 
.13.4 [RFC2252] 
.4.39 [RFC2256] 
.6.16 [RFC2256] 
.6.16.2 [RFC2256] 


caselgnoreOrderingMatch 
caselgnoreSubstringsMatch 
certificateRevocationList 
certificationAuthority 
certificationAuthority-V2 


CN .4.3 [RFC2256] 
cNAMERecord .2342.19200300.100.1.31 [RFC1274] 
co .2342.19200300.100.1.43 [RFC1274] 
commonName .4.3 [RFC2256] 
country .6.2 [RFC2256] 
countryName .4.6 [RFC2256] 
createTimestamp .18.1 [RFC2252] 
creatorsName .18.3 [RFC2252] 


.6.19 [RFC2256] 
.4.40 [RFC2256] 


cRLDistributionPoint 
crossCertificatePair 


DC .2342.19200300.100.1.25 [RFC2247] 
dcObject .6.1.4.1.1466.344 [RFC2247] 
deltaCRL .6.23 [RFC2587] 
deltaRevocationList .53 [RFC2256] 

description .13 [RFC2256] 
destinationIndicator .27 [RFC2256] 

device .14 [RFC2256] 


.49 [RFC2256] 
3.1 [RFC2252] 
.1.4.1.453.7.1.5 [RFC2293] 
:1.44.1.453.7.2.3. [REC2293] 


distinguishedName 
distinguishedNameMatch 
distinguishedNameTableEntry 
distinguishedNameTableKey 
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dITContentRules .21.2 [RFC2252] 
dITRedirect .2342.19200300.100.1.54 [RFC1274] 
dITStructureRules .21.1 [RFC2252] 
dmd .6.20 [RFC2256] 
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dmdName 

dnQualifier 
dNSDomain 

document 
documentAuthor 
documentIdentifier 
documentLocation 
documentPublisher 
documentSeries 
documentTitle 
documentVersion 
domain 
domainComponent 
domainNameForm 
domainRelatedObject 
drink 

dSA 

dSAQuality 
dynamicObject 
dynamicSubtrees 
enhancedSearchGuide 
entryTtl 
extensibleObject 
facsimileTelephoneNumber 
favouriteDrink 
friendlyCountry 
friendlyCountryName 
generalizedTimeMatch 
generalizedTimeOrderingMatch 
generationQualifier 
givenName 

GN 

groupOfNames 
groupOfUniqueNames 
homePhone 
homePostalAddress 
homeTelephone 

host 

houseIdentifier 

info 

initials 
integerFirstComponentMatch 
integerMatch 
internationaliSDNNumber 
janetMailbox 
jpegPhoto 
knowledgeInformation 
L 
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organizationalStatus 
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subtree 
subtreeMaximumQuality 
subtreeMinimumQuality 
supportedAlgorithms 


personalSignature A 0.9.2342.19200300.100. 
personalTitle A 0.9.2342.19200300.100. 
photo A 0.9.2342.19200300.100. 
physicalDeliveryOfficeName A 2.5.4.19 [RFC2256] 
pilotDSA O 0.9.2342.19200300.100. 
pilotObject O 0.9.2342.19200300.100. 
pilotOrganization O 0.9.2342.19200300.100. 
pilotPerson O 0.9.2342.19200300.100. 
pkiCA O 2.5.6.22 [RFC2587] 
pkiUser O 2.5.6.21 [RFC2587] 
postalAddress A 2.5.4.16 [RFC2256] 
postalCode A 2.5.4.17 [RFC2256] 
postOfficeBox A 2.5.4.18 [RFC2256] 
preferredDeliveryMethod A 2.5.4.28 [RFC2256] 
presentationAddress A 2.5.4.29 [RFC2256] 
presentationAddressMatch M 2.5.13.22 [RFC2252] 
protocolInformation A 2.5.4.48 [RFC2256] 
protocolInformationMatch M 2.5.13.24 [RFC2252] 
qualityLabelledData O 0.9.2342.19200300.100. 
ref A 2.16.840.1.113730.3.1. 
referral 0 2:16:840.1.113730.3.2. 
registeredAddress A 2.5.4.26 [RFC2256] 
residentialPerson O 2.5.6.10 [RFC2256] 
RFC822LocalPart O 0.9.2342.19200300.100. 
RFC822Mailbox A 0.9.2342.19200300.100. 
rFC822ToX400Mapping OQ 23-9.10124:13:453:77.1.1 
roleOccupant A 2.5.4.33 [RFC2256] 
room O 0.9.2342.19200300.100. 
roomNumber A 0.9.2342.19200300.100. 
searchGuide A 2.5.4.14 [RFC2256] 
secretary A 0.9.2342.19200300.100. 
seeAlso A 2.5.4.34 [RFC2256] 
serialNumber A 2.5.4.5 [RFC2256] 
simpleSecurityObject O 0.9.2342.19200300.100. 
singleLevelQuality A 0.9.2342.19200300.100. 
SN A 2.5.4.4 [RFC2256] 
SOARecord A 0.9.2342.19200300.100. 
ST A 2.5.4.8 [RFC2256] 
stateOrProvinceName A 2.5.4.8 [RFC2256] 
street A 2.5.4.9 [RFC2256] 
streetAddress A 2.5.4.9 [RFC2256] 
strongAuthenticationUser O 2.5.6.15 [RFC2256] 
subschema O 2.5.20.1 [REC2252] 
subschemaSubentry A 2.5.18.10 [RFC2252] 
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userCertificate 
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B.4. Attribute Description Options 


Option Owner Reference 

binary IESG [RFC2251] 

lang-* IESG [RFC2596] 

* family of options 

B.5. LDAPMessage types 

Name Code Owner Reference 
bindRequest O IESG [RFC2251] 
bindResponse 1 IESG [RFC2251] 
unbindRequest 2 IESG [RFC2251] 
searchRequest 3 IESG [RFC2251] 
searchResEntry 4 IESG [RFC2251] 
searchResDone 5 IESG [RFC2251] 
modifyRequest 6 IESG [RFC2251] 
modifyResponse 7 IESG [RFC2251] 
addRequest 8 IESG [RFC2251] 
addResponse 9 IESG [RFC2251] 
delRequest 10 IESG [RFC2251] 
delResponse 11 IESG [RFC2251] 
modDNRequest 12 IESG [RFC2251] 
modDNResponse 13 IESG [RFC2251] 
compareRequest 14 IESG [RFC2251] 
compareResponse 15 IESG [RFC2251] 
abandonRequest 16 IESG [RFC2251] 
reserved 17-18 IESG 
searchResRef 19 IESG [RFC2251] 
reserved 20-22 IESG 
extendedReq 23 IESG [RFC2251] 
extendedResp 24 IESG [RFC2251] 
B.6. resultCode values 

Name Code Owner Reference 
success O IESG [RFC2251] 
operationsError 1 IESG [RFC2251] 
protocolError 2 IESG [RFC2251] 
timeLimitExceeded 3 IESG [RFC2251] 
sizeLimitExceeded 4 IESG [RFC2251] 
compareFalse 5 IESG [RFC2251] 
compareTrue 6 IESG [RFC2251] 
authMethodNot Supported 7 IESG [RFC2251] 
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strongAuthRequired 
reserved (partialResults) 
referral 
adminLimitExceeded 
unavailableCriticalExtension 
confidentialityRequired 
saslBindInProgress 
noSuchAttribute 
undefinedAttributeType 
inappropriateMatching 
constraintViolation 
attributeOrValueExists 
invalidAttributeSyntax 
noSuchObject 

aliasProblem 
invalidDNSyntax 

reserved (isLeaf) 
aliasDereferencingProblem 


reserved 37- 


inappropriateAuthentication 
invalidCredentials 
insufficientAccessRights 
busy 

unavailable 
unwillingToPerform 
loopDetect 


reserved 55- 


namingViolation 
objectClassViolation 
notAllowedOnNonLeaf 
notAllowedOnRDN 
entryAlreadyExists 
objectClassModsProhibited 


reserved (resultsTooLarge) 
reserved Jl 
other 

reserved (APIs) 81- 
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B.7. Bind Authentication Method 


Method Value Owner Usage Reference 
simple 0 IESG LIMITED USE [RFC2251,RFC2829] 
krbv42LDAP 1 IESG OBSOLETE* [RFC1777] 
krbv42DSA 2 IESG OBSOLETE* [RFC1777] 
sasl 3 IESG COMMON [RFC2251,RFC2829] 


* These LDAPv2-only mechanisms were deprecated in favor of the 
LDAPv3 SASL authentication method, specifically the GSSAPI mechanism. 
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